Exchange Server 2010 Mailbox Services Configuration (part 5) - Configuring Public Folders

8. Configuring Public Folders

Public folders have received a lot of attention for the last two releases of Exchange Server. The rumors of the removal of public folders in Exchange Server 2007 caused an uproar in the messaging community. The fact is that public folders are still supported in Exchange Server 2007 as well as Exchange 2010, and there is good reason for the feature's continued existence as it still fills a need that in some cases is not easily solved by other solutions such as Microsoft Office SharePoint Server or InfoPath. As Table 2 shows, in a number of scenarios public folders still provide a viable solution.

One of the current solutions that SharePoint Server does not fill is that of a multiple-master document share, where document repositories can be replicated to multiple sites to provide access to data at remote sites.

In Exchange Server 2010 public folders support and features have not changed appreciably since Exchange Server 2007 SP1. Despite being a great solution for many client use cases, public folders still remain complex to manage in large environments and complex to recover from when problems arise without third-party tools. One of the only improvements made in Exchange Server 2010 with regard to public folders is that they can now be placed on multiple servers that are in a high-availability configuration, whereas before they were only supported on a single high-availability–configured server and its copy. This may now reduce the number of servers that are deployed because a dedicated public folder server is no longer required.

The choice to use public folders most likely means that either the application requirements are not met by another technology or the company use of public folders is so innate that the migration will take a number of years to complete. It is still important to bear in mind that public folders as they exist today will eventually cease to exist. A new large deployment of public folders should be very carefully scrutinized as to whether it is the best solution.

To understand where public folder replicas need to be placed, it is important to remember how clients find and access replicas. When a user connects with Outlook or Outlook Web App to a public folder the following occurs:

Figure 2 shows how Exchange Server uses Active Directory sites to provide clients with the closest replica of a public folder for a public folder that is not available in the user's default public folder database.

Configuring public folder replicas requires that a detailed Active Directory site topology is understood as well as the methods and locations that the public folder data will be accessed from. A number of methods are chosen for creating replicas for public folders. The primary goal is to keep as few replicas for each folder while maintaining the appropriate access and redundancy.

8.1. Configuring Public Folders for Site Redundancy

As an example, let's look at how Fabrikam uses public folders. A special project team located in the Fresno office uses a set of public folders to store information about their project. Because all of the users are located locally, there is no need to create a replica of the project folders offsite. However, to ensure that data is not lost in the case of a local server failure, at least one offsite replica should be created.

8.2. Configuring Public Folders for Distributed Access

Another example of how public folders can be used can be seen at Litware. Rather than employing SharePoint at this time, the HR department uses a public folder to distribute documentation to all employees for review. This documentation does not change often; however, it is used by all employees on a regular basis. In this case a replica of the public folder should be created at each location so that employees have quick access to these files.

8.3. Designing Public Folder Deployments

In environments where public folders are heavily used, it is a best practice to deploy dedicated public folder servers. This allows for dedicating CPU, memory, and disk resources to isolated server functions, reducing the likelihood of resource contention.

It is also beneficial to have fewer larger public folder databases, rather than having smaller public folder databases. This scales well and is more easily managed and monitored than having several smaller public folder databases. This also reduces the amount of replication traffic that must occur. As with many best practices, it still requires that adjustments be made to fit each environment. As the public folder configuration is designed, the number of databases needed to be deployed must be balanced by the cost of replication traffic and against the costs of management complexity, database backup, maintenance, and restore times.

Another factor to consider is the hierarchy of the public folders. As a general rule, because of how replication is structured it is best to have more nested folders rather than having more folders at the root of the hierarchy. When designing the hierarchy it is also important to consider the permissions that will be granted on the folders. The goal should be to simplify administration and reduce complexity as much as possible when assigning permissions. It is good to have the folders that will have the least restrictive permissions toward the top of the hierarchy, with the folders that require more restrictive permissions to the bottom. Often enterprises will create root folders for each business unit or region and allow departments and project folders to be created below the root folders. However, it is best not to have more than 250 subfolders in each folder.